I've been using HttpRequest in scripts to retrieve data from RQM, but I've noticed that the memory used by the DOORS (9.6) client as shown in the Windows Task Manager continues to grow as my scripts run. Eventually, the DOORS becomes non-responsive as the physical memory usage nears that available on the machine. I think I've tracked down the issue to the HttpRequest command. Even though I delete the HttpResponse object returned after I've extracted the body into a buffer, the actual memory that is used by the HttpRequest call never seems to be released by the process. The amount of memory growth appears to also be directly related to the size of the document being retrieved by HttpRequest, larger document, more memory growth. Repeating the HttpRequest calls using the same parameters and response object also result in an increased rate of memory growth. Has anyone seen anything similar or does anyone have any ideas how to deal with this problem ? Rolan - Tue Jan 26 08:22:33 EST 2016 |
Re: HttpRequest memory growth I have seen lots of problems of this kind. And a lot of times, there are not many chances to solve it, except finding an alternative technology. 1. String Table Littering If you are lucky, you are only littering your string table badly. And if so, you might (but probably will not) be able to resolve the problem by trying to pass tempStringOfs to your APIs instead of normal strings ... E.g: void badApi (string largeDocument) // Instead of Buffer buf = create(); buf = "Very large document" badApi(buf "") // Ouch. // Use: Buffer buf = create(); buf = "Very large document" badApi(tempStringOf buf) 2. Missing Destructor A lot of times this won't help, because the DXL perms will internally use the string table again and therefore leak the memory. Another thing that comes to mind is possible cleanup at the end of the DXL script. Some perms clean up after them only after the DXL script ends. In this case there is a deallocation function, it is only not accessible from DXL. Sometimes it is there, but you simpy do not know that it exists. So first: - Check if the memory goes down after the DXL script ends. If so you might be lucky: - Check the DOORS.exe (or your favourite perms list) for a perm for freeing the request resources - If there is no perm use eval_ for making the request. This way, after making the request the DXL child context will end and the request resources might be freed. E.g.:
// void badApi (string largeDocument);
Buffer bufRequest = create();
string sRequestCode = "
Buffer bufParent = addr_ " ((addr_ bufRequest) int) "
badApi (tempStringOf bufParent)
"
void makeRequest (Buffer buf) {
setempty(bufRequest);
combine(bufRequest, buf, 0); // copy over the contents to the permanent buffer
eval_ sRequestCode
}
Note that a) the badAPI must be availabe inside the eval_ ... and b) that this code might not be 64 bit save due to bad address conversion. I have not make conclusive tests about this.
If neither of these options are a way to go, you can address the problem though architecture. The easiest way would be to create a tool for making the requests in another language (e.g. jscript) and invoke the jscript from the DXL or use a new technology (COM Component) that will allow you to do the same thing. Note however that the COM perms in DOORS also has the same memory problem (string table littering), so do not pass large data over COM. Hope this helps, Regards, Mathias |